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Description 

METHOD AND APPARATUS FOR INTERWORKING BETWEEN 
INTERNET PROTOCOL (IP) TELEPHONY PROTOCOLS 

5 

Priority Application 
This Application claims the benefit of U.S. Provisional Patent 
Application Serial No. 60/137,867 filed June 7, 1999, the disclosure of which 
is incorporated herein by reference in its entirety. 

10 

Technical Field 

The present invention relates to a method and an apparatus for 
interworking between communications protocols. More particularly, the 
present invention relates to a method and an apparatus for interworking 
15 between internet protocol (IP) telephony protocols. 

Background Art 

There are a variety of known protocols for establishing media stream 
communications, such as voice, data, video, or combinations thereof, over 
20 an IP network. Protocols for establishing media stream communications 
over an IP network are referred to herein as IP telephony protocols.. One 
example of an IP telephony protocol is the media gateway control protocol 
(MGCP). MGCP defines signals and events by which a software entity. 




known as a media gateway (MG), is controlled by another software entity, 
known as a media gateway controller (MGC), in a packet network. The 
media gateway controller processes call control signaling from one or more 
signaling gateways (SGs) and utilizes MGCP media control signaling to 
5 establish media streams between MGs. An MGC that processes call control 
signaling in this manner is also referred to as a call agent. The terms media 
gateway controller and call agent are used interchangeably herein. The 
media gateway controller performs call control functions, such as 
translations, resource management, media capabilities negotiation and 
10 selection, and media stream management. It can also provide additional 
services. 

Figure 1 illustrates conventional communications using MGCP. In 
Figure 1, MGC 100 receives call signaling information from SGs 102 and 
103 and controls MGs 104 and 105 to establish packetized media stream 

15 communications between end users in packet network 106. For example, 
SG 102 and MG 104 can be associated with a calling party end user device 
for a given media stream communication. Similarly, SG 103 and MG 105 
can be associated with a called party end user device for a given media 
stream communication. MGC 100 can control MGs 104 and 105 to establish 

20 media stream communications between the called and calling end user 
devices, such as PSTN terminals. 

A detailed explanation of MGCP is found in Media Gateway Control 
Protocol (MGCP), Version 0.1 Draft, Internet Engineering Task Force, 
February 21, 1999, the disclosure of which is incorporated herein by 

25 reference in its entirety. 




Another example of an IP telephony protocol is International 
Telecommunications Union (ITU) Recommendation H.323. H.323 defines a 
protocol by which endpoints, such as gateways, terminals, or multipoint 
control units MCUs), can place calls in a packet network. A gateway 
5 translates between circuit-switched and packet-switched communication 
protocols. A terminal is a device, such as an IP terminal, that provides end 
user access to a network. An MCU is a device that supports conferences 
between three or more endpoints. H.323 defines a gatekeeper as an entity 
that provides address translation and controls access to the packet network 

10 for H.323 endpoints. The gatekeeper can also provide additional services, 
such as call control and supplementary services. 

Figure 2 illustrates an example of conventional H.323 
communications. In Figure 2, a first gateway 200 can be associated with a 
calling end user device and a second gateway 202 can be associated with a 

15 called end user device for a given media communication. Gatekeeper 204 
performs call signaling functions, such as call setup and teardown. to 
establish calls between end user devices associated with gateways 200 and 
202. The end user devices can be PTSN terminals connected to gateway 
200. Alternatively, gateway 200 can be omitted and replaced by H.323 

20 terminals or H.323 MCUs. Once gatekeeper 204 performs the call signaling 
functions necessary to set up a call, the media stream for the call flows 
between gateways 200 and 202. Detailed information relating to H.323 can 
be found in ITU Recommendation H.323, Packet Based Multimedia 
Communications Systems, February 1998, the disclosure of which is 

25 incorporated herein by reference in its entirety. 




Yet another IP telephony protocol is ITU Recommendation H.248. 
The Internet Engineering Task Force (IETF) formed the MEGACO Group to 
evolve the MGCP protocol. As the MEGACO Group matured the protocol, 
the MEGACO Group allied itself with the ITU, and the specification 
5 developed by the MEGACO Group has become known as ITU 
Recommendation H.248. Thus, ITU recommendation H.248 can be viewed 
similarly to MGCP. 

Another IP telephony protocol is the session initiation protocol (SIP). 
SIP is an application layer signaling protocol for creating, modifying, and 

10 terminating sessions between one or more participants. The sessions 
include internet multimedia conferences, internet telephone calls, and 
multimedia distribution. SIP originated from Columbia University and is 
gaining acceptance as a protocol for exchanging call signaling information 
over a packet network. A detailed description of SIP can be found in 

15 Request for Comments (RFC) 2543 SIP: Session Initiation Protocol, March 
1999, the disclosure of which is incorporated herein by reference in its 
entirety. 

In addition to the published protocols described above, many vendors 
of telecommunications equipnient and services are supporting IP telephony 
20 applications via proprietary protocols. 

All of the IP telephony protocols described above are being 
implemented by various vendors. However, standards for interworking 
equipment that communicates using one protocol with equipment that 
communicates using another protocol are immature, nonexistent, or focus 
25 only on a specific type of application. Accordingly, there exists a long-felt 




need for a novel method and apparatus for intenworking between IP 
telephony protocols. 

Disclosure of the Invention 
5 The present invention provides a novel method and apparatus for 

interworking between IP telephony protocols. Although most of the 
examples described below relate to MGCP and H.323, it Is understood that 
the method and apparatus described herein are applicable to any IP 
telephony protocol. 

10 Many of the protocols described herein define an entity that is 

responsible for performing functions and requests on behalf of a telephony 
device. Typically, these functions and requests include translations, media 
capabilities exchange, and other services. The entities that perform the 
functions can be logical, physical, or both. For example, in MGCP, the MGC 

15 or call agent performs call signaling functions on behalf of a gateway. In 
H.323, the gatekeeper performs call signaling functions for an H.323 
gateway. In SIP, a proxy server performs call signaling functions for an end 
user. In order to facilitate a description of the present invention, the term call 
server is used herein to refer to an entity that performs call signaling 

20 functions, such as translations and media capabilities exchange, on behalf of 
an end user device, gateway, or other entity. 

According to a first aspect, the present invention includes a call server 
including a first protocol agent and a second protocol agent. The first 
protocol agent communicates with a first protocol device according to a first 

25 protocol. The second protocol agent communicates with a second protocol 




device according to a second protocol. An interworking agent provides 
functions usable by the first and second protocol agents to comnnunicate 
using a third protocol. The third protocol provides a superset of the functions 
provided by the first and second protocols. 
5 Accordingly, it is an object of the present invention to provide a novel 

method and apparatus for interworking between IP telephony protocols. 

An object of the invention having been stated hereinabove, and which 
is achieved in whole or in part by the present invention, other objects will be 
evident as the description proceeds, when taken in connection with the 
1 0 accompanying drawings as best described hereinbelow. 

Brief Description of the Drawings 
A description of the present invention will now proceed with reference 
to the accompanying drawing of which: 
15 Figure 1 is a block diagram illustrating conventional MGCP network 

entities; 

Figure 2 is a block diagram illustrating conventional H.323 network 
entities; 

Figure 3 is a block diagram illustrating media gateway controller and 
20 gatekeeper functions implemented within a call server according to an 
embodiment of the present invention; 

Figure 4 is a block diagram illustrating a call server wherein each call 
half is represented by an agent according to an embodiment of the present 
invention; 




Figure 5 is a block diagram illustrating a call server including a 
plurality of intenA/orking agents according to an embodiment of the present 
invention; 

Figure 6 is a block diagram illustrating protocol agents implementing 
5 originating and terminating call half functions executing on different 
machines wherein an intenA/orking agent is associated with each protocol 
agent; 

Figure 7 is a block diagram illustrating a call server including MGCP, 
interworking, and H.323 agents for interworking MGCP and H.323 entities 
1 0 according to an embodiment of the present invention; 

Figure 8 is a block diagram illustrating a connection information 
parameter data structure according to an embodiment of the present 
invention; 

Figures 9(a) and 9(b) are flow charts illustrating message tunneling 
1 5 according to an embodiment of the present invention; 

Figure 10 is a block diagram illustrating exemplary agent interworking 
protocol message structures according to an embodiment of the present 
invention; 

Figure 1 1 is a block diagram illustrating an exemplary data structure 
20 for a digit information parameter according to an embodiment of the present 
invention; 

Figure 12 is a call flow diagram illustrating exemplary call signaling for 
H.323 fast start to MGCP communications according to an embodiment of 
the present invention; 
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Figure 13 is a call flow diagram illustrating H.323 non-fast-start to 
MGCP communications according to an embodiment of the present 
invention; 

Figure 14 is a call flow diagram illustrating exemplary call signaling for 
5 a hold scenario between H.323 and North American Q.931 endpoints 
according to an embodiment of the present invention; 

Figure 15 is a call flow diagram illustrating exemplary call signaling for 
a retrieve scenario between H.323 and North American Q.931 endpoints 
according to an embodiment of the present invention; 
10 Figure 16 is a call flow diagram illustrating exemplary call signaling for 

a hold scenario between H.323 and MGCP endpoints according to an 
embodiment of the present invention; 

Figure 17 is a call flow diagram illustrating exemplary call signaling for 
a retrieve scenario between H.323 and MGCP endpoints according to an 
1 5 embodiment of the present invention; 

Figure 18 is a call flow diagram illustrating exemplary call signaling 
between H.323 and MGCP endpoints for common channel signaling 
according to an embodiment of the present invention; and 

Figure 19 is a call flow diagram illustrating exemplary call signaling 
20 between an MGCP gateway and an H.323 gateway according to an 
embodiment of the present invention. 



25 



Detailed Description of the Invention 
The present invention provides a novel method and apparatus for 
interworking between IP telephony protocols. In order to provide this 
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interworking. a call server includes agents that communicate with other 
entities according to the protocols implemented by the other entities. 
However, the protocol agents communicate with each other utilizing a 
protocol-independent agent interworking protocol (AlP). As a result, network 
5 entities that implement different protocols can seamlessly communicate with 
each other. 

Figure 3 illustrates a call server including MGC and GK functions 
according to an embodiment of the present invention. In Figure 3, a call 
server 300 includes an MGC function 302 and a GK function 303. The call 

10 server is a software entity that can execute on a single machine or on 
multiple machines. MGs and SGs recognize call server 300 as an MGC. 
H.323 endpoints, such as gateways, recognize call server 300 as a GK. For 
example, in the illustrated embodiment, jngress MG 304, egress MG 306, 
and SG 308 recognize call server 300 as an MGC. Similarly, ingress H.323 

15 gateway 310 and egress H.323 gateway 312 recognize call server 300 as a 
gatekeeper. 

In order for MGs 304 and 306 to recognize call server 300 as an 
MGC, MGC function 302 in call server 300 is adapted to communicate with 
MGs 304 and 306 using MGCP. Similarly, in order for SG 308 to recognize 

20 call server 300 as an MGC. MGC function 302 in call server 300 
communicates with SG 308 using a call signaling protocol, such as ISDN 
Part (ISUP). In order for H.323 gateways 310 and 312 to recognize call 
server 300 as a gatekeeper, gatekeeper function 303 in call server 300 
communicates with gateways 310 and 312 according to ITU 

25 Recommendations H.225 and H.245. 
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Figure 4 illustrates an embodiment of call server 300 in which the call 
processing functions illustrated in Figure 3 are separated into call agents, 
each of which performs call half functions. As used herein, call half functions 
refer to functions associated with either the originating or terminating side of 
5 a call. For example, in Figure 4, MGCP function 302 illustrated in Figure 3 is 
divided into MGCP agent 302A and MGCP agent 302B. Similarly, H.323 
function 303 illustrated in Figure 3 is divided into H.323 agent 303A and 
H.323 agent 303B. MGCP agent 302A and H.323 agent 303A can perform 
call originating functions, such as collection of digits and translations. MGCP 

10 agent 302B and H.323 agent 303B can perform call terminating functions, 
such as trunk selection and alerting the called party of an incoming call. The 
functions performed by each call half will be explained in detail below with 
reference to call flow diagrams. 

As mentioned above, the present invention is not limited to 

15 interworking between MGCP and H.323 entities. For example, Figure 5 
illustrates a call server including protocol agents configured to communicate 
with other agents using a variety of different protocols. In the illustrated 
embodiment, call server 300 includes MGCP agents 302A and 302B for 
processing MGCP to MGCP calls, H.323 agents 303A and 303B for 

20 processing H.323 to H323 calls, H.323 agent 500A and MGCP agent 500B 
for processing H.323 to MGCP calls, H.323 agent 502A and SIP agent 502B 
for processing H.323 to SIP calls, and H.323 agent 504A and NAQ.931 
agents 504B for processing H.323 to NAQ.931 calls. In addition, to the 
protocol agents, call server 300 also includes an intenworking agent 506 

25 which facilitates communication between protocol agents. More particularly. 




interworking agent 506 includes methods for getting and setting AlP 
parameters, building AlP messages, and establishing and maintaining 
connections, such as TCP or reliable UDP connections, between protocol 
agents. Interworking agents can also identify AlP message types, which will 
5 be described in more detail below. Thus, as illustrated in Figure 5, 
interworking agent 506 provides functions usable by a variety of different 
protocol agents to provide seamless interworking between the protocol 
agents. 

In a preferred embodiment of the invention, the interworking agent is 
1 0 divided into separate software components, one component associated with 
the protocol agent for each call half. The division of the interworking agent 
into two software components allows protocol agents associated with a given 
call to execute on separate machines. 

Referring to Figure 6, call server 300 illustrated in Figure 5 is divided 
15 into call servers 300A, 300B. and 300C, which can execute on the same 
machine or on different machines. Call server 300A includes protocol agents 
that perform both originating and terminating call half functions. Call servers 
300B and 300C each include protocol agents that perform only originating or 
terminating call half functions. This division of call processing functionality is 
20 enabled by interworking agents components 506A and 506B, which enable 
protocol agents to communicate with each other using AlP messaging. 
Exemplary information that can be exchanged using AlP messaging includes 
information regarding call progress, media capabilities and addresses, 
supplementary services, etc. By allowing the protocol agents to reside on 




separate machines, the interworking agents according to embodiments of 
the present invention allow efficient division of call processing functions. 

Figure 7 illustrates an example of an MGCP-H.323 network typology 
wherein communication between MGCP and H.323 endpoints occurs 
5 through a call server according to an embodiment of the present invention. 
In Figure 7, call server 300 includes MGCP agent 700A for performing 
originating call half functions according to the media gateway control 
protocol and H.323 agent 700B for performing terminating call half functions 
according to the H.323 protocol. More particularly, MGCP agent 700A 

10 communicates with ingress media gateway 304 according to the media 
gateway control protocol and with signaling gateway 306 according to a call 
signaling protocol, such as ISUP. H.323 agent 700B communicates with 
H.323 gateway 312 according to H.225 and H.245 protocols. MGCP agent 
700A and H.323 agent 700B communicate with each other using AlP 

15 messaging. Interworking agent components 702A and 702B provide the 
functions that protocol agents 700A and 700B use to formulate and process 
AlP messages. 

Because the interworking agent components 702A and 702B provide 
functions for converting messages to and from a protocol independent 
20 format, MGCP agent 700A and the H.323 agent 700B need not be aware of 
each other's protocol. Similarly, MG 304 and SG 306 need not be aware of 
the protocol of H.323 gateway 312. and H.323 gateway 312 need not be 
aware of the protocol of MG 304 and SG 306. 



Agent Interworkinq Protocol 
As stated above, interworking agents according to embodiments of 
the present invention communicate with each other according to a protocol 
independent format referred to as the agent interworking protocol. The 
5 agent interworking protocol is preferably capable of representing a 
reasonable superset of the messaging capabilities of all protocols to be 
supported within the packet network. Designing an interworking protocol 
that supports all of the capabilities of all of the supported protocols is an 
unnecessarily burdensome task since some capabilities are rarely used or 

10 are only useful when communicating between devices that support the 
particular protocol. In addition, these rarely used capabilities can be 
communicated between agents that support these capabilities using 
tunneling, as will be described in more detail below. Accordingly, it is 
desirable that the agent interworking protocol provide a reasonable superset 

15 of the capabilities of supported protocols. 

Rather than designing an entirely new protocol for use as the agent 
interworking protocol, it is more desirable to select an existing protocol that 
comes close to meeting the superset definition described above and 
extending that protocol. Existing protocols that could be used as the base 

20 protocol for the agent interworking protocol include Q.931, ISUP, and SIP. 
The agent interworking protocol implemented in interworking agents 
according to preferred embodiments of the present invention is based upon 
ISUP. For example, AlP includes traditional ISUP messages such as initial 
address messages (lAM). answer messages (ANM), and release messages 

25 (REL). The agent intenA^orking protocol extends the base protocol to include 




additional procedures and signaling required to meet interoperability 
requirements. The functions and data structures used in the agent 
interworking protocol to meet these requirements will now be discussed in 
more detail. 

5 One function that must be provided by the agent interworking protocol 

is a method for exchanging media capabilities between protocol agents. 
Each of the agent protocols to be interworked provide some means by which 
a telephony device can make known the media capabilities that it supports. 
These capabilities must be exchanged between two devices that desire to 
10 participate in a media stream communication in order to select a mutually 
compatible media session definition. 
1:3 Capabilities Exchange Between H.323 Devices 

H.323 allows an endpoint to advertise its capabilities at two different 
'=n times - during call establishment and after call establishment. For example. 

O 15 some H.323 devices support fast start capabilities which allow a partial list of 

;;t media capabilities to be exchanged in H.225 call establishment messages. 

This method of exchanging capabilities allows faster establishment of a 
media stream between endpoints because capabilities are exchanged during 
call signaling, rather than waiting until after call signaling has been 
20 completed. In order to exchange capabilities after call establishment, H.323 
compliant devices use H.245 signaling to provide a full description of all 
media capabilities supported. 

Capabilities Exchange Between MGCP and SIP Devices 
MGCP and SIP support the use of the session description protocol 
25 (SDP) for encoding the capabilities supported by the device. The session 



description protocol is included in call establishment messages similarly to 
H.323 fast start messages. For example, a SIP call establishment message, 
such as an INVITE message, includes an SDP portion in the body of the 
message. The SDP portion includes the capabilities supported by the 
5 endpoint, such as encoding and decoding algorithms, type of media stream, 
etc. 

Because these capabilities can be exchanged during call setup or 
after call establishment, the agent interworking protocol implemented in call 
servers according to embodiments of the present invention is preferably 
10 flexible enough to support capabilities exchange at either time. In addition, 
because each of the above-mentioned protocols uses different syntax for 
specifying the capability's definition, AlP preferably provides a normalized 
syntax to which interworking agents can map the capability's definitions. 

Media Management 

15 In addition to providing a method for exchanging media capabilities, 

the agent interworking protocol preferably also provides media management 
capabilities that include a reasonable superset of the media management 
capabilities of supported protocols. For example, each of the agent 
protocols provide support for establishing and altering media streams; 

20 however, the specific protocols vary significantly. H.323 fast start 
procedures allow H.323 devices to establish a media stream in concert with 
call establishment. However, fast start is optional and might not be 
supported by a given H.323 device. H.245 procedures allow H.323 devices 
to open and close media channels post call establishment. H.323 is very 

25 limited in its ability to alter a media stream once established. H.323 media 
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streams can be unidirectional or bi-directional. Voice/audio media is typically 
represented via two independent unidirectional streams on IP networks with 
bi-directional media being typically used for data or for voice on ATM 
networks. 

5 MGCP supports establishment of media streams during call 

establishment similar to H.323 fast start procedures. Media streams can be 
either unidirectional or bi-directional and can be changed from one format to 
the other at any time during a call. MGCP allows media channels to be 
modified in a variety of ways without having to be closed. For example, a 

10 media stream can be redirected by changing the receiving real time protocol 
(RTP) address. The encoding format can be changed by changing the 
codec. The mode can be changed to send only, send receive, receive only, 
or inactive. SIP is similar to MGCP in its ability to modify media streams. 

In order to provide an interworking solution that accommodates these 

1 5 agent protocols, three design objectives are preferably met. The first design 
objective is that the agent interworking protocols must provide sufficient 
flexibility to meet the requirements of all agent protocols. Second, the agent 
design preferably maps between agent specific and AlP procedures and 
syntax for media management. The third objective is that a flexible control 

20 framework is preferably implemented that allows the agent to easily react to 
media changes made by the agent implementing the other call half. The 
connection information parameter illustrated in Figure 8 is the mechanism 
provided by the agent interworking protocol for implementing media 
management functions and exchanging media capabilities. The times for 

25 exchanging media capabilities and performing media management functions 




according to the agent intenworking protocol will be described in more detail 
below with respect to the call flow diagrams. 

Figure 8 is a table illustrating exemplary fields and field values for the 
connection information parameter according to an embodiment of the 
5 present invention. In Figure 8, the left hand column represents the fields in 
the connection information parameter data structure. The right hand column 
represents example values for each of the fields in the left hand column. In 
the illustrated embodiment, the connection information parameter includes a 
media type field 800 that holds a media type value 802 for specifying the 

10 type of media being exchanged or sought to be exchanged in a media 
stream. Example values for the media type field include audio, video, and 
data. Channel ID field 804 includes an internally assigned channel ID value 
that allows an interworking agent to identify the media stream. In the 
illustrated embodiment, 12345 is given as an example value 806 for channel 

15 ID field 804. Channel operation field 808 includes a channel operation value 
810 for specifying the operation being performed on the media stream. 
Values 810 for the channel operation field 808 are preferably a superset of 
protocol media stream operations for the supported protocols. In the 
illustrated embodiment, exemplary values for the channel operation field are 

20 no action, open, close, modify, mode change, redirect, direct, and send 
capabilities. The no action value indicates that no change is being made to 
the existing media stream. The open value specifies that a media stream is 
sought to be opened. The close value indicates that an open media stream 
is sought to be closed. The modify value indicates that the media stream is 

25 sought to be modified, e.g., changing a code from G.711 to G.729a. The 
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mode change value indicates that the mode of the media stream is sought to 
be changed, e.g., from send only to receive only. The redirect value 
indicates that the media stream is to be redirected to another endpoint. The 
direct value specifies the location to which the media stream is to be 
5 directed. The send capabilities value requests the receiving entity to transfer 
the media capabilities list. 

Current media description field 812 stores current media description 
value 814 for indicating the description of the current media stream. In the 
illustrated embodiment, an example of a current media description value is 

10 G.71 1 at two frames per packet. Media capabilities field 816 includes media 
capabilities value or values 818 that allows an entity to exchange its media 
capabilities with another entity. In the illustrated example, the media 
capabilities field includes a list of supported formats, such as G.711, G.729. 
Media capabilities field 818 also includes a payload size value that specifies 

15 the size of media capabilities field. Media capabilities field 818 also includes 
a redefinable area in which information specific to the type of media and 
codes can be specified. For example, a facsimile media stream requires 
certain attributes that are not required for other media types. The 
redefinable area allows this information to be specified. 

20 Message Tunneling 

As described above, the agent interworking protocol represents a 
reasonable superset of the agent protocols sufficient to achieve interworking. 
However, the agent interworking protocol is not a complete superset of the 
supported protocols. That is, certain agent protocols can contain messages 

25 or parameters which do not map to any other agent protocols, but provide 




added value for a call between two devices of the same type. In this case,* 
the agent interworking protocol preferably supports tunneling of the native 
protocol message. As used herein, tunneling refers to transferring the native 
protocol message from one protocol agent to another protocol agent without 
5 converting to and from the agent interworking protocol. The agent receiving 
the native protocol message can inspect the message, and if the agent 
understands the message, process the message accordingly. 

An example of when it might be desirable to tunnel a message relates 
to H.323. H.323 provides a sophisticated means of representing terminal 

10 capabilities in sets. The agent interworking protocol, as described herein, 
might not include functionality for representing terminal capabilities in sets as 
defined in H.323, because the other protocols do not support such capability. 
Another capability that H.323 supports which can not be supported by other 
protocols is the exchange of H.245 indications between two H.323 devices. 

15 Some of these indications have no equivalent mapping to other agent 
protocols. In these situations, it can be desirable to tunnel the H.323 
messages from one agent to another agent. 

Method of Tunneling Messages 
According to an embodiment of the present invention, interworking 

20 messages can be of three types: 

• Agent interworking protocol messages - protocol-neutral messages 
understood by all protocol agents; 

• Native protocol messages - protocol-specific messages, such as SIP, 
MGCP, and H.323 messages; 
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• Multipart messages - messages that contain multiple other messages, 
such as native protocol messages and AlP messages. All agents are 
preferably capable of extracting the AlP message and processing the 
message accordingly. If the multipart message contains a native 
5 protocol message, this message is preferably processed if supported. 

Figures 9(a) and 9(b) are flow charts illustrating exemplary 
formulating and processing of interworking messages by a call server 
according to an embodiment of the present invention. The flow chart in 
Figure 9(a) illustrates exemplary steps that can be performed by a sending 
10 protocol agent in formulating an interworking message using procedures 
provided by an associated interworking agent. The flow chart in Figure 9(b) 
illustrates exemplary steps that can be performed by a receiving protocol 
agent using procedures provided by an associated interworking agent upon 
receiving an interworking message. Referring to Figure 9(a), in step ST1, 
1 5 the sending protocol agent receives a message from an external entity, such 
as an H.323 gateway. In step ST2, the sending protocol agent determines 
whether a mapping is available to the agent interworking protocol. In step 
ST3, if a mapping is available, the sending protocol agent formulates the 
corresponding AlP message using functions provided by the interworking 
20 agent associated with the sending protocol agent (hereinafter, "the first 
interworking agent") and transmits the message to the receiving protocol 
agent (step ST4). In step ST2, if the sending protocol agent determines that 
the mapping to the agent interworking protocol is not available, the sending 
protocol agent simply transmits the protocol message without modification to 
25 the receiving protocol agent (step ST4). In step ST2, if the sending protocol 



agent determines that a mapping to AlP is partially available, the sending 
protocol agent can formulate a multiprotocol message including the AlP 
message and the native protocol message (step ST5). The sending protocol 
agent can then transmit the multiprotocol message to the receiving protocol 
5 agent (step ST4). 

Referring to Figure 9(b), in step ST6, the receiving protocol agent 
receives the message from the sending protocol agent. In step ST7, 
receiving protocol agent determines the message type, i.e., whether the 
message is a protocol specific message, an agent interworking protocol 

10 message, or a multipart message, using procedures provided by its 
associated intenA/orking agent (hereinafter, "the second interworking agent"). 
In step ST8, if the receiving protocol agent determines that the message is 
an agent interworking protocol message, the receiving protocol agent 
processes the message (step ST9). In step ST10, the receiving protocol 

15 agent determines whether the message is a multipart message. If the 
message is a multipart message, the receivinjg protocol agent separates the 
multi-protocol message into its component messages (step ST11). After the 
receiving protocol agent separates the message, the receiving protocol 
agent reads the protocol specific portion of the AlP message (step ST12). In 

20 step ST13, the receiving protocol agent determines whether the protocol in 
the protocol specific portion is supported. If the protocol is not supported, 
the receiving protocol agent discards the message (step ST14). If the 
protocol is supported, the receiving protocol agent processes the message 
(step ST15). In step ST16, the receiving protocol agent processes the AlP 

25 portion of the message. 



# - • 

Referring to step ST17, if the receiving protocol agent determines that 
the message is a protocol specific message, the receiving protocol agent 
determines whether the protocol of the message is supported (step ST18). 
If the protocol is supported, the receiving protocol agent processes the 
5 message (step ST19). If the protocol is not supported, the receiving protocol 
agent discards the message (step ST20). 

Transport Mechanism for Agent Interworkinq Messages 
Interworking messages can be sent between protocol agents using 
any packet based protocol, for example. TCP. UDP, etc. In a preferred 

10 embodiment of the invention, interworking messages are transmitted 
between interworking agents using TCP over IP. As is known in the art, an 
IP message includes a header portion and a data portion. A TCP message 
is encapsulated in the data portion of the IP message. The TCP message 
also includes a header portion and a data portion. Interworking messages 

15 are encapsulated in the data portion of the TCP message. Interworking 
messages also include a header portion and a data portion. The header 
portion indicates the message type, i.e., AlP, protocol-specific, or multipart. 

Figure 10 illustrates the relationships between IP messages, TCP 
messages, and interworking messages. In Figure 10, IP message 1000 

20 includes a header portion 1002 and a data portion 1004. TCP message 
1006 is encapsulated in data portion 1004 of IP message 1000. TCP 
message 1006 includes a header portion 1008 and a data portion 1010. 
Interworking message 1012 is encapsulated in data portion 1010 of TCP 
message 1006. Interworking message 1012 includes a header portion 1014 

25 for indicating the message type and a data portion 1016 containing the 



actual message. If the header portion 1014 indicates that the interworking 
message is a multipart message, data portion 1016 of interworking message 
1012 includes a first field 1018 indicating the number of messages present in 
the multipart message. After the first field, the multipart message can 
5 include one or more interworking messages 1012A to 1012N. 

DTMF Digit Handling 
Another extension of the base protocol provided by the agent 
interworking protocol is dual tone multifrequency (DTMF) digit handling. 
Numerous studies have concluded that encoding and transporting DTMF 
10 digits within the media stream is not suitable for supporting networked 
S services, such as credit card validation, automated services, and voice mail, 

3 which require DTMF digit recognition. Some of these services require 

0 recognition not only of the tone being transmitted but also of the duration of 

n the tone. Algorithms for encoding voice and data can distort the tone and/or 

3 15 change the duration of the tone sought to be transmitted. As a result, the 

^ receiving application might not be able to correctly interpret the tone. 

2 Currently, a fully standardized approach for handling the transport of 

DTMF digits after call establishment is not defined. The approach that is 
currently in the most favor is to encode DTMF digits as a special real time 
20 protocol (RTP) payload type that is exchanged between devices participating 
in the media stream. If this approach is standardized, various digital signal 
processor (DSP) manufacturers must comply with the standard before 
interworking will be accomplished. Because this involves a hardware 
change, much time can elapse before this occurs. 
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As a current solution to the problem, some of the agent . protocols 
have implemented out-of-band techniques for handling DTMF digits. The 
agent interworking protocol according to embodiments of the present 
invention preferably provides a mapping to and from the out-of-band DTMF 
5 digit handling techniques of supported protocols. In order to provide a 
method for communicating DTMF information between protocol agents, the 
agent interworking protocol defines a data structure referred to herein as the 
digit information parameter. Figure 11 illustrates an exemplary digit 
information parameter data structure. In the illustrated embodiment, the digit 

10 information parameter data structure includes a digit field 1100 and a 
duration field 1102. Digit field 1100 is capable of storing a digit value 
indicative of the DTMF digit being transmitted. For example, the digit field 
can contain a numerical value that indicates one of the keys on a telephone 
handset. Duration field 1102 stores a duration value for indicating the 

15 duration of the tone represented by the digit in the digit field. Specific 
examples of when the digit information parameter is exchanged will be 
explained below with reference to the call flow diagrams. 

Interworking Examples 
A. H.323 Fast Start to MGCP 

20 Figure 12 is a call flow diagram illustrating exemplary call signaling 

performed by H.323 and MGCP agents including interworking agent 
capabilities according to an embodiment of the present invention. In Figure 
12, H.323 endpoint 1200 is seeking to establish a call with an MGCP 
endpoint through MGCP gateway 1202. MGCP gateway 1202 performs 

25 both signaling gateway and media gateway functions. H.323 agent 1204 



includes interworking agent functionality and implements an originating call 
model. MGCP agent 1206 includes interworking agent functionality and 
implements a terminating call model. 

In line 1 of the call flow diagram, H.323 endpoint 1200 sends a 
5 SETUP message to H.323 agent 1204. The SETUP message includes fast 
start parameters that specify suggested media options for the initial media 
stream. In line 2 of the call flow diagram H.323 agent 1204 sends an agent 
interworking protocol initial address message (lAM) to MGCP agent 1206. 
The AlP lAM message contains the media capabilities definition mapped 

10 from the fast start parameters extracted from the SETUP message. In line 3 
of the call flow diagram, MGCP agent 1206 sends an MGCP create 
connection (CRCX) message to MGCP gateway 1202. The CRCX message 
contains local connection options that are mapped from the AlP media 
capabilities information extracted from the lAM message into MGCP format. 

15 In line 4 of the call flow diagram, MGCP gateway 1202 sends an OK 
message to MGCP agent 1206. The OK message includes a media 
capability selected by MGCP gateway 1202 from the media capabilities 
specified in the CRCX message. The media description for the selected 
capability is returned in the SDP portion of the OK message. 

20 In line 5 of the call flow diagram, MGCP agent 1206 sends an AlP call 

progress (CGP) message to H.323 agent 1204. An AlP CPG message is 
used to signal events other than release and answer between protocol 
agents implementing different call halves. In the illustrated example, the 
CPG message includes a mapping of the SDP portion of the OK message 

25 into AlP format. In addition, any other media capabilities which the MGCP 
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agent is capable of supporting can be included in the media description. In 
line 6 of the call flow diagram, H.323 agent 1204 transmits an ALERTING 
message to H.323 endpoint 1200. H.323 agent 1204 maps the media 
description from the AlP CPG message into fast start parameters and 
5 includes the fast start parameters in the ALERTING message. Any 
additional capabilities that were received by the H.323 agent are stored for 
later usage. 

In line 7 of the call flow diagram, when the MGCP end user answers 
the call, signaling gateway 1202 sends a NOTIFY message to MGCP agent 
10 1206. The NOTIFY message alerts MGCP agent 1206 of the off-hook event. 
In line 8 of the call flow diagram, in response to the NOTIFY message, 
MGCP agent 1206 transmits an AlP answer message (ANM) to H.323 agent 
1204. 

In line 9 of the call flow diagram, in response to the answer message, 
15 H.323 agent 1204 transmits a CONNECT message to H.323 endpoint 1200. 
In lines 10 and 11 of the call flow diagram. H.323 endpoint 1200 and H.323 
agent 1204 exchange master/slave and master/slave acknowledge 
messages. These messages are sent according to H.245 master/slave 
determination. This determination is made to resolve conflicts in media 
20 formats. H.323 agent 1204 handles the exchange and does not map the 
exchange to the agent interworking protocol. 

In line 12 of the call flow diagram, H.323 endpoint 1200 transmits an 
H.245 terminal capabilities set (TCS) message to H.323 agent 1204 to 
communicate the media capabilities of endpoint 1200 to H.323 agent 1204. 
25 In line 13, H.323 agent 1204 acknowledges the TCS message. In lin^ 14 of 



the call flow diagram, H.323 agent 1204 transmits a multipart message to 
MGCP agent 1206. The multipart message includes the capabilities of the 
H.323 device mapped into AlP format. The capabilities are sent to MGCP 
agent 1206 in the AlP CPG message. Optionally, the H.245 representation 
5 of the TCS can be sent as well. In this case, a multipart message is sent 
between call halves. The multipart message includes both the AlP CPG 
message and the H.245 TCS message. Because MGC 1206 might not 
support H.245 TCS, MGCP agent 1206 might, i.e., if H.245 TCS is not 
supported, discard the TCS portion of the multipart message and process 

1 0 only the AlP portion. 

In lines 15 and 16 of the call flow diagram. H.323 endpoint 1200 and 
H.323 agent 1204 exchange TCS and TCS ACK messages. In this 
exchange, the capabilities of the other end, i.e., of MGCP gateway 1202, 
which were received and stored upon receipt of the CPG message in line 5 

15 of the call flow diagram, are sent to H.323 endpoint 1200 as an H.245 
terminal capability set. 

H.323 Non-Fast Start to MGCP 
While Figure 12 illustrated H.323 to MGCP interworking for H.323 fast 
start procedures, Figure 13 illustrates H.323 to MGCP interworking without 
20 fast start procedures. In other words, in Figure 13. the H.323 media 
capabilities are not exchanged until after call establishment. The entities, 
involved in communications in Figure 13 are the same as those illustrated in 
Figure 12. Thus, a description of these entities is not repeated herein. 

Referring to Figure 13, in line 1 of the call flow diagram, H.323 
25 endpoint 1200 sends a SETUP message to H,323 agent 1204. The SETUP 
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message does not include fast start parameters. In line 2 of the call flow 
diagram, H.323 agent 1204 transmits an AlP lAM message to MGCP agent 
1206. The lAM message contains no media description. In other words, the 
connection information parameter is either not included or set to a null value. 
5 In line 3 of the call flow diagram, MGCP agent 1206 transmits a CRCX 
message to MGCP gateway 1202. The CRCX message can optionally 
contain a default set of media capabilities that do not reflect capabilities 
supported by the H.323 endpoint. A CRCX message example is as follows: 
CRCX: 

10 R:HD 
13 L: Default media capabilities 

□ M: Inactive (or receive only) 

=0 In the CRCX message example, the hd value in the R field instructs gateway 

W 1202 to go ofl^hook. The value in the L field specifies local connection 

O 15 options, which indicate to gateway 1202 the media capabilities of H.323 

endpoint 1200. In response to the CRCX message, in line 4 of the call flow 
;=| diagram, MGCP gateway 1202 transmits an OK message to MGCP agent 

1206. The OK message includes an SDP portion with the media description 
for the connection. An exemplary media description is as follows: 
20 v=0 

c=IP address 
m=media description 
In the exemplary media description set forth above, the IP address in the c= 
parameter is the IP address on MGCP gateway 1202 for receiving the media 
25 stream. The media description specified in the m= parameter includes the 



type of media that the media gateway is capable of receiving, e.g., voice, 
data, or video. 

In line 5 of the call flow diagram, MGCP agent 1206 transmits an AlP 
call progress (CPG) message to H.323 agent 1204. The AlP CPG message 
5 includes the connection information parameter data structure in which the 
media description from the SDP portion of the AlP message is mapped into 
AlP format. The media description is stored by H.323 agent 1204, but is not 
transmitted to H.323 endpoint 1200 as a fast start parameter. 

In line 6 of the call flow diagram, H.323 agent 1204 transmits an 

10 ALERTING message to H.323 endpoint 1200. The ALERTING message 
notifies H.323 endpoint 1200 that the MGCP end user is being alerted. 
When the MGCP end user answers the call, in line 7 of the call flow diagram, 
MGCP gateway 1202 transmits a NOTIFY message to MGCP agent 1206. 
In line 8 of the call flow diagram, MGCP agent 1206 transmits an AlP answer 

15 message (ANM) to H.323 agent 1204. In line 9 of the call flow diagram. 
H.323 agent 1204 transmits a CONNECT message to H.323 endpoint 1200. 
In lines 10 and 11 of the call flow diagram, the H.245 master/slave 
determination takes place. H.323 agent 1204 handles the exchange and 
does not map the exchange to the agent interworking protocol. 

20 In lines 12 and 13 of the call flow diagram H.323 endpoint 1200 and 

H.323 agent 1204 exchange H.245 TCS and H.245 TCS ACK messages. 
This exchange communicates the media capabilities of H.323 endpoint 1200 
to H.323 agent 1204. In line 14 of the call flow diagram, H.323 agent 1204 
transmits a multipart message to MGCP agent 1206. H.323 agent 1204 

25 maps the capabilities of H.323 endpoint 1200 into AlP format and includes 



these capabilities in an AlP CPG message. Optionally, the H.245 
representation of the TCS can be sent as well. In this example, a multipart 
message is sent that includes both the AlP CPG message and the H.245 
TCS message. Since MGCP agent 1206 can not support H.245 TCS, MGCP 
5 agent 1206 can only process the AlP portion of the multipart message. 

In lines 15 and 16 of the call flow diagram, H.323 endpoint 1200 and 
H.323 agent 1204 exchange TCS and TCS ACK messages. In this 
exchange, the capabilities of MGCP gateway 1202, which were received and 
stored upon receipt of the AlP CPG message in line 5 of the call flow 
10 diagram, are sent to H.323 endpoint 1200 as an H.245 terminal capability 
2 set. In lines 17 - 20 of the call flow diagram, H.323 endpoint 1200 and H.323 

a agent 1204 exchange H.245 OPEN LOGICAL CHANNEL and H.245 OPEN 

LOGICAL CHANNEL ACKNOWLEDGE messages. In this exchange, H.323 
agent 1204 two unidirectional media streams between the end users. H.323 
O 15 endpoint 1200 returns its RTP port for each media stream in the 

acknowledge messages. 

;2 In line 21 of the call flow diagram, H.323 agent 1204 transmits an AlP 

CPG message to MGCP agent 1206. CPG message contains an updated 
media description to reflect the RTP address of H.323 endpoint 1200 and 
20 the mode change to send receive. In line 22 of the call flow diagram, MGCP 
agent 1206 transmits a modify connection message to MGCP gateway 1202. 
This updates the media description at MGCP gateway 1202 and a full duplex 
media path between end users is complete. 



H.323-NAQ.931 Call Hold Scenario 
Figure 14 illustrates interworking between an H.323 endpoint and an 
NAQ.931 device for a call hold scenario. In Figure 14, it is assumed that a 
bi-directional media stream has been established between H.323 endpoint 
5 1200 and NAQ.931 device 1400. H.323 endpoint 1200 can be an IP 
terminal, as previously described with respect to Figure 12. NAQ.931 device 
1400 can comprise an IP terminal. H.323 agent 1402 includes interworking 
agent capabilities as well as H.323 gatekeeper capabilities. Similarly, 
NAQ.931 agent 1404 includes interworking agent capabilities as well as 

10 NAQ.931 agent capabilities. 

In line 1 of the call flow diagram, NAQ.931 device 1400 transmits a 
HOLD message to NAQ.931 agent 1404. In line 2 of the call flow diagram, 
in response to the HOLD message, NAQ.931 agent 1404 transmits an AlP 
CPG message to H.323 agent 1402. The CPG message includes the 

15 connection information parameter data structure. The channel operation 
field in the data structure is set to mode change, and the mode field in the 
data structure is set to inactive. In line 3 of the call flow diagram, H.323 
agent 1402 transmits a TCS = 0 message to H.323 endpoint 1200. In line 4 
of the call flow diagram, H.323 agent 1402 transmits a CLOSE LOGICAL 

20 CHANNEL message to H.323 endpoint 1200. The CLOSE LOGICAL 
CHANNEL message closes one of the two channels between H.323 
endpoint 1200 and NAQ.931 device 1400. In line 5 of the call flow diagram, 
NAQ.931 agent 1404 transmits a FACILITY message to NAQ.931 device 
1400. The FACILITY message indicates that inactive mode has been 

25 entered. In line 6 of the call flow diagram, H.323 endpoint 1200 transmits a 
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CLOSE LOGICAL CHANNEL ACKNOWLEDGE message to H.323 agent 
1402 acknowledging the closing of logical channel 1 . 

In lines 7 and 8 of the call flow diagram, H.323 endpoint 1200 and 
H.323 agent 1402 exchange H.245 CLOSE LOGICAL CHANNEL and 
5 CLOSE LOGICAL CHANNEL ACKNOWLEDGE messages for logical 
channel 2. Once logical channel 2 is closed, in line 9 of the call flow diagram 
H.323 agent 1402 transmits an AlP CPG message to NAQ.931 agent 1404. 
The AlP CPG message includes the connection information parameter. The 
change operation field in the connection information parameter data 

1 0 structure is set to mode change, and the mode is set to inactive. 

H.323 - NAQ.931 Call Retrieve Scenario 
Figure 15 illustrates H.323 to NAQ.931 interworking for a call retrieve 
scenario. The entities illustrated in Figure 15 are the same as those 
illustrated in Figure 14. Hence, a description thereof is not repeated herein. 

15 In Figure 15, it is assumed that a call between H.323 endpoint 1200 and 
NAQ.931 device 1400 has been put on hold. Thus, the signaling that must 
occur between H.323 endpoint 1200 and NAQ.931 device 1400 to retrieve 
the call includes reopening the logical channels between H.323 endpoint 
1200 and NAQ.931 device 1400. 

20 In line 1 of the call flow diagram illustrated in Figure 15. NAQ.931 

device 1400 transmits a RETRIEVE message to NAQ.931 agent 1404. In 
line 2 of the call flow diagram. NAQ.931 agent 1404 transmits an AlP CPG 
message to H.323 agent 1402. The CPG message includes the connection 
information parameter data structure with the change operation field set to 

25 mode change and the mode set to send/receive. In lines 3 and 4 of the call 



flow diagram, the H.245 master/slave determination occurs between H.323 
endpoint 1200 and H.323 agent 1402. H.323 endpoint 1200 and H.323 
agent 1402 must revert to a TCS exchange in order to reestablish the media 
streams. Accordingly, in lines 5 and 6 of the call flow diagram H.323 
5 endpoint 1200 and H.323 agent 1402 exchange TCS and TCS ACK 
messages. 

In line 7 of the call flow diagram H.323 endpoint 1200 transmits an 
H.245 OPEN LOGICAL CHANNEL to H.323 agent 1402. In line 8 of the call 
flow diagram, H.323 agent 1402 transmits an AlP CPG message to 

10 NAG. 931 agent 1404. The CPG message includes the connection 
information parameter data structure. The channel operation field and the 
data structure is set to mode change and the mode is set to send only. This 
reestablishes one of the media streams between H.323 endpoint 1200 and 
NAQ.931 device 1400. In line 9 of the call flow diagram, NAQ.931 agent 

15 1404 transmits a FACILITY message to NAQ.931 device 1400. The 
FACILITY message includes a mode parameter that sets the channel to be 
receive only. 

In line 10 of the call flow diagram H.323 agent 1402 transmits an 
OPEN LOGICAL CHANNEL ACKNOWLEDGE message to H.323 endpoint 

20 1200 acknowledging the opening of logical channel 1. In line 11 of the call 
flow diagram, H.323 agent 1402 transmits an H.245 OPEN LOGICAL 
CHANNEL message to H.323 endpoint 1200 to open logical channel 2. In 
line 12 of the call flow diagram, H.323 endpoint 1200 transmits an H.245 
OPEN LOGICAL CHANNEL ACKNOWLEDGE message to H.323 agent 

25 1402. In line 13 of the call flow diagram, H.323 agent 1402 transmits an AlP 
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CPG message to NAQ.931 agent 1404. The CPG message includes the 
connection information parameter data structure. The channel operation 
field in the data structure is set to mode change and the mode field is set to 
send/receive. In line 14 of the call flow diagram, NAQ.931 agent 1404 
5 transmits a FACILITY message to NAQ.931 device 1400. The FACILITY 
message includes a mode field that sets the mode to be send/receive. Once 
this message is received, both logical channels are open between H.323 
endpoint 1200 and NAQ.931 device 1400. 

H.323 - MGCP Hold Scenario 

10 Figure 16 illustrates intenworking for an H.323 - MGCP hold scenario. 

In Figure 16, it is assumed that a call has been established between H.323 
endpoint 1200 and MGCP device 1600. MGCP device 1600 is assumed to 
support an event package for call hold and retrieve events. H.323 device 
1200 is the same as H.323 device 1200 described with respect to Figure 12, 

15 and hence a description thereof is not repeated herein. MGCP device 1600 
can be an MGCP device, such as a media gateway. MGCP agent 1602 
includes interworking agent functionality as well as MGCP media gateway 
controller functionality. H.323 agent 1402 is the same as H.323 agent 1402 
described with respect to Figure 14, and hence a description thereof is not 

20 repeated herein. 

In line 1 of the call flow diagram, MGCP device 1600 transmits a 
NOTIFY message to MGCP agent 1602. The NOTIFY message includes an 
event that informs MGCP agent 1602 that the end user connected to MGCP 
device 1600 has placed the call on hold. In line 2 of the call flow diagram, 

25 MGCP agent 1602 transmits an AlP CPG message to H.323 agent 1402. 



The AlP CPG message includes the connection information parameter. The 
channel operation field in the connection information parameter data 
structure is set to mode change and the mode field is set to inactive. In line 
3 of the call flow diagram, H.323 agent 1402 transmits a TCS = 0 message 
5 to H.323 endpoint 1200. 

In lines 4 and 5 of the call flow diagram, H.323 endpoint 1200 and 
H.323 agent 1402 exchange CLOSE LOGICAL CHANNEL messages to 
close the logical channel between H.323 endpoint 1200 and MGCP device 
1600. In line 6 of the call flow diagram, MGCP agent 1602 transmits a 

10 MODIFY connection (MDCX) message to MGCP device 1600 indicating that 
the mode has been set to inactive. In lines 7 and 8 of the call flow diagram, 
H.323 endpoint 1200 and H.323 agent 1402 exchange the messaging 
required to close logical channel 2. H.323 agent 1402 interprets the inactive 
mode as a hold and applies H.323 third party calls and rerouting procedures 

15 to implement the hold actions. These procedures result in the closing of 
both unidirectional media streams between H.323 endpoint 1200 and MGCP 
device 1600. In line 9 of the call flow diagram, H,323 agent 1402 transmits 
an AlP CPG message to MGCP agent 1602. The CPG message includes 
the connection information parameter data structure. The channel operation 

20 field in the connection information data structure is set to mode change, and 
the mode field is set to inactive. 

H.323 - MGCP Retrieve Scenario 
Figure 17 illustrates an H.323 - MGCP retrieve scenario. The entities 
illustrated in Figure 17 are the same as those illustrated in Figure 16, and 

25 hence a description thereof is not repeated herein. In Figure 17, it is 
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assumed that a call between H.323 endpoint 1200 and MGCP device 1600 
has been placed on hold. 

In line 1 of the call flow diagram, MGCP device 1600 transmits a 
NOTIFY message to MGCP agent 1602. The NOTIFY message contains an 
5 event that indicates to MGCP agent 1602 that the end user connected to 
MGCP device 1600 wishes to retrieve the call. In line 2 of the call flow 
diagram, MGCP agent 1602 transmits an AlP CPG message to H.323 agent 
1402. The AlP CPG message includes the connection information 
parameter data structure. The channel operation field in the data structure is 
10 set to mode change, and the mode field is set to send/receive. 

^ In lines 3 and 4 of the call flow diagram. H.323 agent 1402 and H.323 

LJ endpoint 1200 make a master/slave determination. The H.323 devices must 

revert to a TCS exchange in order to reestablish the media streams. 

5 Accordingly, in lines 5 and 6 of the call flow diagram, H.323 agent 1402 and 

3 15 H.323 endpoint 1200 exchange terminal capabilities. 

I In line 7 of the call flow diagram, H.323 endpoint 1200 transmits an 

3 H.245 open logical channel message to H.323 agent 1402 to open one of 

the logical channels between H.323 endpoint 1200 and MGCP device 1600. 
In line 8 of the call flow diagram, H.323 agent 1402 transmits an AlP CPG 
20 message to MGCP agent 1602. The AlP CPG message includes the 
connection information parameter data structure. The change operation field 
in the data structure is set to mode change, and the mode field is set to send 
only. In line 9 of the call flow diagram, MGCP agent 1602 transmits a modify 
connection message to MGCP device 1600. The modify connection 
25 message includes a mode field setting the mode to receive only. In line 10 
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of the call flow diagram H.323 agent 1402 acknowledges the H.245 open 
logical channel messages transmitted in line 7 of the call flow diagram. 

In lines 11 and 12 of the call flow diagram, H.323 endpoint 1200 and 
H.323 agent 1402 exchange messaging for opening the other logical 
5 channel between H.323 endpoint and MGCP device 1600. In line 13 of the 
call flow diagram, H.323 agent 1402 transmits an AlP CPG message to 
MGCP agent 1602. The CPG message includes the connection information 
parameter data structure. The channel operation field in the data structure is 
set to mode change, and the mode field is set to send/receive. In line 14 of 
10 the call flow diagram, MGCP agent 1602 transmits a modify connection 
S message to MGCP device 1600. The modify connection message instructs 

^ the device to change the mode to send/receive. At this point, both media 

Q streams between H.323 endpoint 1200 and MGCP device 1600 are 

h established. 

3 15 H.323 to MGCP Primarv Rate Interface (PRI) 

^ Common Channel Signaling (CCS) 

3 Figure 18 illustrates exemplary call signaling for H.323 to MGCP PRI 

(CCS). In Figure 18, signaling gateway 1800 relays call control signaling 
between a circuit-switched network and a packet-switched network. For 
20 example, signaling gateway 1800 may be connected to a PSTN end office 
on one side and to an IP network on the other side. In the illustrated 
embodiment, signaling gateway 1800 is configured to forward Q.931 call 
signaling messages from the PSTN network to a packet network and vice- 
versa. On the circuit-switched side, SG 1800 can be configured to send and 
25 receive Q.931 over Q.921 call signaling messages. On the packet-switched 



side, signaling gateway 1800 can be configured to send and receive Q.931 
over ISDN User Adaptation over TCP/IP messages. 

Media gateway 1802 converts between packets and circuits to 
communicate the media stream to and from a PSTN end user device. On 
5 the circuit-switched side, media gateway 1802 can send and receive the 
media stream using pulse code modulation (PCM) voice. On the packet- 
switched side, media gateway 1802 can send and receive the media stream 
using RTP over UDP/IP. In the illustrated embodiment, media gateway 1802 
is controlled using MGCP. 

10 CCS agent 1804 exchanges call control information with signaling 

gateway 1800 and media control information with media gateway 1802. In 
the illustrated embodiment, CCS 1804 communicates with signaling gateway 
1800 using Q.931 call signaling over lUA over TCP/IP and with media 
gateway 1802 using MGCP. CCS agent 1804 also communicates with 

15 H.323 agent 1806 using the agent interworking protocol, as described 
above. It is understood that CCS agent 1804 and H.323 agent 1806 can be 
part of a call server. H.323 agent 1806 and H.323 gateway 1808 exchange 
call signaling information according to ITU Recommendation H.225. 

In line 1 of the call flow diagram, signaling gateway 1800 transmits a 

20 SETUP message to CCS agent 1804. The SETUP message includes 
information, such as the dialed digits for creating a call with the called party. 
In line 2 of the call flow diagram CCS agent 1804 transmits a CALL 
PROCEEDING message to signaling gateway 1800 to indicate that CCS 
agent 1804 is attempting to establish a call with the called party. In line 3 of 

25 the call flow diagram, CCS agent 1804 sends an MGCP CREATE 



CONNECTION message to media gateway 1802. In response to the 
CREATE CONNECTION message, media gateway 1802 transmits an 
ACKNOWLEDGE message including an SDP portion that specifies the 
supported media capabilities of media gateway 1802. In line 5 of the call 
5 flow diagram, CCS agent 1804 transmits an AlP lAM message to H.323 
agent 1806. The AlP lAM message includes the connection information 
parameter that specifies the supported media capabilities of media gateway 
1802. In line 6 of the call flow diagram, H.323 agent 1806 transmits a 
SETUP message specifying the media capabilities of media gateway 1802 to 

10 H.323 to H.323 gateway 1808. In line 7 of the call flow diagram. H.323 
gateway agent 1808 transmits an ALERT message to H.323 agent 1806 
indicating that the called part is being alerted, of the incoming call. The 
ALERT message includes the supported media capabilities of H.323 
gateway 1808. In line 8 of the call flow diagram, H.323 agent 1806 sends an 

15 AlP CALL PROGRESS message including the connection information 
parameter specifying the media description of H.323 gateway 1808. In line 9 
of the call flow diagram, CCS agent 1804 transmits an ALERT message to 
signaling gateway 1800 indicating that the called party is being alerted. 

In line 10 of the call flow diagram, CCS agent 1804 transmits an 

20 MGCP MODIFY CONNECTION message specifying the mode of the 
connection as receive only and including the media description of H.323 
gateway 1808. In line 11 of the call flow diagram, media gateway 1802 
acknowledges the MODIFY CONNECTION message. 

In line 12 of the call flow diagram, when the called party answers the 

25 call, H.323 gateway 1808 transmits a CONNECT message to H.323 agent 



1806. In line 13 of the call flow diagram, in response to receiving the 
CONNECT message, H.323 agent 1806 transmits an AlP ANSWER 
message to CCS agent 1804. In line 14 of the call flow diagram, CCS agent 
1804 transmits a CONNECT message to signaling gateway 1800 indicating 
5 that the call has been answered. In line 15 of the call flow diagram, CCS 
agent 1804 transmits a MODIFY CONNECTION message to media gateway 
1802 opening the connection as send/receive. In line 16 of the call flow 
diagram, media gateway 1802 acknowledges the MODIFY CONNECTION 
message. At this point, a bi-directional media stream communication is 
10 established between the called and calling parties. Thus, the call flow 
diagram illustrated in Figure 18 embodies the true MGCP reference 
architecture whereby the SG and MG are separate entities. 



MGCP-H.323 Call Setup and Exchange of DTMF Digits 
15 Figure 19 illustrates call signaling and exchange of DTMF digits 

between an MGCP gateway and an H.323 gateway. The entities illustrated 
in Figure 19 are the same as those illustrated in Figure 16. Hence, a 
description thereof is not repeated herein. 

In Figure 19 it is assumed that a connection has already been 
20 established between H.323 endpoint 1200 and MGCP device 1600. 
Therefore, call setup and teardown messages are not shown. 

In line 1 of the call flow diagram, H.323 endpoint 1200 transmits a 
user input indication message to H.323 agent 1402 that includes the DTMF 
digit * encoded in the message. In line 2 of the call flow diagram, H.323 
25 agent 1906 transmits an AlPJNFO message to MGCP agent 1602 that 
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indicates that information is being communicated to MGCP agent 1602. The 
AlPJNFO message includes the digit information parameter that specifies 
the DTIVIF digit entered by the end user connected to H.323 gateway 1902. 
In line 3 of the call flow diagram. MGCP agent 1602 transmits a MODIFY 
5 CONNECTION message to MGCP device 1600. The modify connection 
message includes a signal indicating the DTMF digit *. In line 4 of the call 
flow diagram, MGCP device 1600 acknowledges the modify connection 



10 changed without departing from the scope of the invention. Furthermore, the 
foregoing description is for the purpose of illustration only, and not for the 
purpose of limitation — the invention being defined by the claims. 




message. 



It will be understood that various details of the invention can be 



